The present invention relates generally to enhanced domain name servers (DNS), and more particularly, to efficiently processing domain name (DN) queries in a network.
The Internet has experienced explosive growth in recent years and provides a vast resource of information on a wide array of topics. The Internet requires DNS for providing Internet Protocol (IP) addresses corresponding to the DNs. The response time of any DNS query, however, is highly dependent on the latency of the Internet. In addition, the availability of any response varies with the packet loss rate of the Internet. DNS developers attempted to address these problems by including a cache memory in local servers. FIG. 1 is a state diagram showing a process flow of traditional DNS processing.
To access a remote computer over the Internet, a user types in the DN or URL (Universal Resource Locator) of that remote computer (e.g., www.example.com) using a browser at a local computer 110 (step 160). Most Internet connections begin by a query to a local server 120 to obtain the IP address of that computer (e.g., 128.96.41.1). To do so, local server 120 looks in its local cache storing previous queries. If the current query is for an IP address that matches a previous query, local server 120 can respond to the query immediately using the information stored in the local cache.
If local server 120 does not find the answer in the local cache, however, local server 120 relays the query to a root server 130 (step 161). Root server 130, or more precisely the "top level domain server," knows the address of all "remote servers" that manage second level names (e.g., example.com). Root server 130 transmits redirection information, i.e., name and IP address of the remote server (e.g., dns.example.com) to local server 120 (step 162). Thereafter, local server 120 repeats the query, this time to the specified remote server 140 (e.g., dns.example.com) (step 163). Remote server 140 in turn, transmits the IP address of the requested DN to local server 120 (step 164). Local server 120 stores a copy of this answer in its local cache and provides an answer to local computer 110 (step 165). Using the IP address, local computer 110 establishes connection with remote computer 150 (step 166).
Subsequently, if local computer 110 repeats the same query (step 167), local server 120 looks in the local cache and will find the IP address. Local server 120 then transmits the address to local computer 110 without having to access other components of the network (step 168), thus enabling local computer 110 to establish connection to remote computer 150 (step 169).
Referring to FIG. 2, a special case occurs when a user mistypes or guesses the DN, making up such names as "www.i-dont-really-know.com" (step 200). Similar to the above-explained process flow, local server 120 checks its local cache. But since local server 120 will not find the DN in the local cache, it relays the query to root server 130 (step 201). Thereafter, root server 130 checks a reference database to determine whether the DN exits and returns an error message to local server 120 (step 202). Local server 120, in turn, relays the error message to local computer 110 (step 203).
Some local servers keep a copy of these error messages, but typically only for a short period of time since a name that is not found one day may well be registered the next. Moreover, copies of error messages are only useful if users keep repeating the exact same mistake, an unlikely event. In practice, most wrong guesses result in a transaction to one of the root servers, thus extending the DN processing time and subjecting communications to problems with Internet traffic.
Moreover, due to the dramatic increase in the size of the Internet since the late 1980's, the caching technique no longer provides high quality results. Typically, fewer than 85% of queries are served in less than three seconds. This is expected to worsen as the Internet grows.
Therefore, it is desirable to increase the efficiency in processing DN queries for connecting local computers to remote computers.
It is also desirable to provide efficient processing of invalid DNs.